close/reopen for testing purposes.

I don't understand the azure testing

• I still see a [build in progress] for over 8 hours
• For some reason the azure numpy.numpy-old pipeline is triggered for this PR

Yeah, somehow the test list has become cluttered in the process of experimentation. In this case, the tests seem to have completed in the stalled queue, which is the same as 'azure ci ...' and 'azure-pipeline...' but it didn't update. I suspect a timing glitch. Not sure why the old queue is still running, but suspect it is set up to respond. I'll delete it at some point now that I have figured out how to do that, but was a bit concerned that previous tests would be lost.

I think that azure doesn't archive old tests beyond 30 days or so, so that is something else we might want to look into.

Looks like newer PRs are just running just one pipeline, so I think this is just a glitch.

More experimentation.

Can you try to rebase on master? The error on azure looks to be due to the old multithreaded testing.

I reran the mac test manually and it passed. I'm thinking that the numpy.numpy (1) problem is due to changing the name while a test was in progress.

Lets see if a rebase clears the in-progress build

If you hit the checks button, you can examine the test runs for the time. The only recent check is the azure-pipeline one.

The mailing list had one response which was positive and proposed to encode even more info. I left room for the extra information in the lower bits for a future PR to extend this one.

Not clear why the macos pipeline failed

The idea of caching the python module version in C met with a -1 on the mailing list, a different idea of creating a sys.version_info-like tuple in python seems to have more support. In #11175 we incremented NPY_API_VERSION and used that instead as it is more appropriate.